In today's software environment, a large and increasing number of applications rely on databases to store and retrieve information. These applications typically use a software component that operatively connects the application to the database allowing the application to store and retrieve the data it needs. Since this software component is coupled between the application and the database, it is commonly referred to as middleware. In the field of database access, this middleware component can be called a database driver or database provider, depending on the programming environment for which the middleware is designed.
When developing database drivers or providers, there are often cases where the developer must choose between providing certain functionality at the expense of performance, or vice versa. However, the set of goals, constraints and operations performed by database applications and the environment in which those applications operate are usually different for each of the applications. As such, trading off performance for functionality may be the correct choice for some applications and not for others. To help resolve this inconsistency, database drivers and providers typically provide a set of options that allow the user to choose whether a particular tradeoff is appropriate for their application, in affect customizing the driver or provider to that application.
The problem is that even the simplest of drivers or providers have many options that the user may configure, and in some cases two or more of the options are related such that the setting of one affects how the other option(s) should be set. The user often times is not a database expert and typically is not aware of all of the options available for a given driver or provider. Even when the user does know about all of the options, determining what the best value for each option is for their particular application is time consuming and not trivial.
What is needed are techniques for configuring database access middleware for optimal performance.